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CARD, DEVICE, PRODUCT AND PRODUCT MANAGEMENT SYSTEM 

The present invention relates to a system for managing 
products associated with cards and devices, for example, 
5 payment, loyalty, identification, access, insurance, 
information and transportation products. 

By "card" we mean, broadly, any apparatus that can be 
used to facilitate product transactions (typically with a 
card-accepting device) . This includes magnetic-striped 
10 cards, smart cards, "virtual" cards ("wallets"), memory 
cards, microprocessor cards, contactless cards, optical 
cards, laser cards, embossed cards, tickets, boarding 
passes, coupons, and printed cards. It also includes any 
apparatus which might not be a card but which may provide 
15 for similar functionality. 

By "device" we mean, broadly, any apparatus, that can 
be used to facilitate product transactions (typically with 
a card). This includes ATM' s , EFTPOS terminals, draft 
capture terminals, card accepters, contactless card 
20 readers, optical readers, laser readers, ticket readers, 
boarding pass readers, coupon readers, and imprinters. 

The use of apparatus such as cards and/or devices for 
facilitating product transactions is ubiquitous. Note that 
by the term "product" we mean the application that the card 
25 and/or device associated with the product is arranged to 

facilitate. There are a large number of such products and 
a potential for many more. They include (but are not 
limited to) : 

1. Payment products - e.g. credit, charge, debit, 
30 stored value, purchasing, payphone, calling, and account 

billing products. 

2. Loyalty products - e.g., airline frequent flier, 
product coupon, retailer discount and customer frequency 
products . 



3. Identification products - e.g., license, ID, 
passport and electronic signature products. 

4. Access products - e.g., building, computer, 
mobile phone, device and security access products. 

5. Insurance products - e.g., health, motor vehicle 
and general insurance products. 

6. Information products - e.g., medical, health, 
personal, computer, motor vehicle service and portable 
information file products. 

7. Transport ticketing products - e.g., airline 
ticket and boarding pass, rapid transit ticketing, car 
park, parking meter and toll road transport products. 

These products are often but not exclusively card 
based. 

The management of card- and/or device-related 
products, as well as the associated message data, is 
complex. Any product usually requires the involvement of a 
number of different participants. In a credit card 
product, for example, the participants involved will 
usually include the following: 

1. Card Issuer. This may be an entity such as a 
bank that issues and/or subsequently manages a card 
for facilitating the credit product, to a cardholder. 
Note that the card issuer may outsource certain 
functions to third parties (e.g., card manufacturing 
to a card-manufacturing bureau, to specifications 
provided by the card issuer) ; 

2. Cardholder. This is usually the person holding 
the card. Note that the cardholder may be an 
inanimate object such as a motor vehicle, or a 
.corporation who assigns the card to a position or 
function . 

3. Transaction Acquirer. This may be an entity such 
as a bank that installs and/or subsequently manages a 
device that accepts cards to facilitate a credit 



product transaction, to a card accepter. The 
transaction acquirer is typically responsible for the 
management of transactions initiating from these 
devices (e.g., the routing of product transactions 
received from and sent to the devices, the routing of 
product transactions to processors to facilitate the 
approval and/or processing of product transactions). 
The transaction acquirer may in some cases be the same 
entity as the card issuer (e.g., where the same bank 
that issues the card acquires the product 
transaction) . Note that the transaction acquirer may 
outsource certain functions to third parties (e.g., 
product transaction switching to a transaction- 
switching bureau, to specifications provided by the 
transaction acquirer) . 

4. Card Accepter. This is usually the participant 
accepting the card and presenting the product 
transaction to the transaction acquirer via the 
device. The card accepter in the case of a credit 
card may be a retail merchant. 

In addition to the above, particularly in the case of 
credit cards, a "scheme operator" participant may also be 
involved. Product transactions may be routed via a scheme 
operator from the device or transaction acquirer to the 
card issuer for approval and/or processing of the product 
transaction. Examples of scheme operators include VISA® 
and MASTERCARD®. 

The transaction acquirer may need to authorise the 
product transaction with the card issuer, before the 
transaction is approved. Authorisation for the transaction 
may be sought on-line directly from the card issuer, via a 
scheme operator (where a scheme is involved) or a third 
party ("stand in" ) . 

The transaction acquirer will need to clear and settle 
the product transaction with the card issuer, as well as 



provide the product transaction to the card issuer so it 
can be processed. In credit card transactions, this can be 
done in a number of ways. Where the transaction acquirer 
and the card issuer are the same participant, it can be 
settled and provided for processing directly with the card 
issuer (an "on us" product transaction) . Where the 
transaction acquirer and the card issuer are different 
participants, it can be settled and provided for processing 
through a bilateral interchange agreement or via a scheme 
operator (where a scheme is involved) interchange 
arrangement ("off us"). 

In a credit card system, the card accepter usually 
pays a fee to the transaction acquirer, who in turn usually 
pays a fee to the card issuer (as well as the scheme 
operator or third party, if applicable) . In some cases, 
the cardholder will also pay a fee to- the card-issuer 
and/or card accepter. Alternately, the flow of fees 
between the various participants may be reversed in some 
cases . 

Other types of products than credit cards may include 
variations on the above, but they will be substantially 
similar. For loyalty programs, for example, a bureau may 
be involved for the calculation of loyalty points. 

Management of such products and the relationships 
between the participants involved is complex. Any 
management system (s) must be able to carry out a large 
number of processes and manage information enabling the 
management of the product and relationships. For example, 
the management system (s) must be able to: 

1. make decisions and conduct processes based on 
product transaction content; 

2. route product transactions to and from devices 
and other participants; 

3. obtain and maintain information on card holders, 
card accepters and other participants; 
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4 . support cryptographic processing (messages may be 
encrypted) . 

The implementation of any product may necessarily 
involve negotiations between various entities involved to 
5 decide on the product operating parameters and data that 
will be required. A management system(s) will then be 
designed to operate the product, including devices and 
processing systems for processing the necessary product 
transactions and other data. Such dedicated systems do not 

10 easily lend themselves to alteration or adaptation to 
facilitate operation of additional or other products. 

For example, a product scheme and product package may 
overlap, such as where a VISA® or MASTERCARD® credit 
product issued by one bank is tied to a package of products 

15 in a confined locality (e.g., the Qantas/Telstra/Visa 
scheme in Australia or the American Express/American 
Airlines/Hilton Hotels scheme in North America) . 

Present card and/or device product management systems 
therefore have a number of problems. Firstly, as discussed 

20 above, they are not readily adaptable to support 
significant changes in the product. 

Secondly, if a card or device is lost or damaged and 
requires replacement, it can be a complex matter to obtain 
all the necessary information to reissue the card or re- 

25 establish the device. This is particularly the case where 
a card and/or device may be associated with more than one 
product (e.g., a credit card product and a loyalty scheme 
product supported by the same card and/or device) . 
Information may have to be obtained from a number of 

30 different entities in order to reissue the card and/or re- 
establish the device. 

The presently available management systems limit the 
extent by which cards associated with different products 
can be implemented (multi-product cards) . Likewise, the 

35 presently available management systems also limit the 
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extent to which devices supporting different products can 
be established (multi-product devices) . The more products 
that there are associated with a card and/or device, the 
more negotiation is required between the different 
participants and the more complex the management system(s) 
required. One of the major benefits of smart cards which 
is often touted is their ability to support many different 
products on a single card. A cardholder may therefore only 
need to carry one or two cards that support all the 
products that they may require. The present management 
systems stand in the way of the implementation of multi 
product cards, as well as multi-product devices. 

The present management systems often result in product 
operating errors and delays in completing transactions, 
particularly where the product is one of a multiple-product 
system. The present multiple-product • systems generally 
arise by the addition of a further product to an already 
existing card/device based product. The management system 
is amended or added to to cope with the further product. 
For example, where the further product includes a loyalty 
scheme, presently transaction information from the primary 
product, (e.g. credit card product) will undergo further 
processing to establish data associated with the loyalty 
product. Primary participants in this system are the 
25 managers of the credit card product (e.g. transaction 

acquirer and card issuer for the credit card product) . To 
enable the loyalty product the primary participants provide 
further separate processing. For example, the transaction 
acquirer and the card issuer may be a bank. The bank is 
responsible for processing a transaction it receives from 
devices associated with the credit card product. As well 
as transactions associated with the credit card product, in 
a separate process (usually carried out in batch) the bank 
must determine which of the credit product transactions are 
associated with card holders who belong to the loyalty 
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scheme. The data from those transactions is then used to 
calculate loyalty points. Loyalty points are often 
calculated by a separate bureau which receives the relevant 
transaction data from the bank. The loyalty points may 
then be passed on to the loyalty product manager. The 
transaction data processed by the transaction acquirer will 
include the same data whether the transaction is associated 
with the loyalty scheme or not. The transaction acquirer 
(or other entity processing the transactions) must first of 
all "match up" the transaction data with the loyalty scheme 
(which may be by identifying the card holder the 
transaction is associated with determining whether or not 
that card holder is a member of the loyalty scheme) and 
then pass only the relevant transactions onto the loyalty 
product manager (or bureau) . 

This system can result in errors and delays. For 
example, it may take weeks or even months for loyalty 
points to be credited to a card holders account. In some 
cases, loyalty points may not be allocated at all. 

Further, redemption of loyalty points is done as a 
totally separate process, which is also slow and requires 
effort by the card holder. 

In such a system there is no real control of the 
loyalty product by the product manager. Further, there is 
no product as such on the card or device. The card and 
device system have been constructed to support the primary 
product (e.g. the credit card product) and operation of the 
further product is done "behind the scenes" . • There is no 
information in the transaction for the loyalty product 
manager. Separate "batch processing" must be provided by 
the transaction acquirer. 

The present "card processing environment" can be 
considered either a single role environment (where all 
product transactions are "on us") or a dual role 
environment (where at least some product transactions are 
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"off us" ) . In the case of a single role environment, the 
card issuer is also the transaction acquirer. In the case 
of a dual role environment, the card issuer and transaction 
acquirer may be separate. It should be noted that there 
5 might be multiple participants carrying out a particular 
role (i.e., multiple card issuers and multiple transaction 
* acquirers within a dual role environment) . 

Where a further product is involved being managed by a 
separate product manager participant, such as described 

10 above, the product manager is an indirect participant. 
Indirect participants rely on the participants in the 
single role or dual role environment to provide them with 
the information necessary for them to manage the product. 
They are not directly involved in the "card processing 

15 environment" . The raw data provided in the transaction is 
not usable by the further indirect participant. Further 
processing must be provided by a separate process. 

The present applicants have identified the possibility 
of a further role being involved in the card processing 

20 environment to facilitate the management of card device- 
based products, particularly where multiple products are to 
be supported by cards and/or devices. The applicants have 
termed this third role a "product owner". The product 
owner is an entity who can be considered to "own" a product 

25 associated with the card and/or device. The product owner 
may be responsible for the management of the product in 
isolation of other card and/or device management 
requirements (i.e., they may not be responsible for the 
issuing or management of cards, nor the establishment or 

30 management of devices) . As some of the previous functions 
of the card issuer may be transferred to the product owner, 
the applicants have re-named the previous card issuer role 
as "card manager". Likewise, as some of the previous 
functions of the transaction acquirer may be transferred to 
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the product owner, the applicants have re-named the 
previous transaction acquirer role as "device manager" . 

1 Note that a product may be implemented as a product 
application on a card, on a device, or distributed on both 
5 card and the device. Smart cards in particular facilitate 
the provision of product applications on the card. The 
* management system of the present invention, however, 
although particularly appropriate for the smart card 
environment may also be implemented to manage products 

10 which may not be on the card, which may be on the device, 
or which may be neither on the card or on the device. 

The present invention provides a card device and 
product management system, including a card management 
means which enables a card manager participant to perform a 

15 card management role alone, without managing products 
associated with a card and without managing devices; 

a device management means which enables a device 
manager participant to perform a device management role 
alone, without managing products associated with the card 

20 and without managing cards; and 

a product management means, which enables a product 
owner participant to perform a product management role 
alone, without managing cards and without managing devices, 
whereby all three roles can be performed by separate 

25 entities. 

The terms "card", "device" and "product" have the 
definitions which are given above. To amplify on those 
definitions, however, the "card" includes any means which 
enables representation of a relationship between a card 

30 holder and a card manager. In the simplest terms, it may 
include merely an identification number or account number. 
It is a guarantee that the card holder is enabled to carry 
out the product transaction. It may include a token or 
electronic wallet which is utilisable over a computer 

35 network such as the Internet, from a card holder's PC. 
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Similarly, a "device" is anything capable of 
representing a relationship between a device manager 
(transaction acquirer) and a card acceptor (merchant) . It 
may be a "virtual" device accessible via a Web page on the 
5 Internet, for example . 

The addition of a product owner role to the single or 
'dual environment, preferably creates a "tripartite 
environment' 7 , where there may be three roles required to 
facilitate the management of card and/or device-associated 
10 products : 

1. the management of cards being carried out by the 
card manager. 

2. The management of devices, being carried out by 
the device manager. 

15 3. The management of a product being carried out by 

the product owner . 

Note that all these roles may in some circumstances be 
carried out by the same participant, i.e. operating each of 
the device management means, product management means and 

20 card management means. 

Each of the product management means, card management 
means and device management means preferably includes a 
software module controlling a processing means to 
facilitate the product owner, card manager and device 

25 manager roles . 

The system preferably further comprises a message 
management means which is arranged to manage the routing of 
message data between cards, devices and the card, device 
and product management system. In a preferred embodiment, 

30 the message management means includes a software module 

which can control a processing means to control the routing 
of message data. Note that by message data is meant any 
data including transaction data, that needs to be routed 
within the system. Preferably, each participant in the 

35 system is provided with a message management module. For 
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example, where the card manager, product owner and device 
manager are separate entities, each of the entities will 
have 1 a message management means to control the routing of 
message data within the system, i.e. between the management 
5 means and the cards and devices. 

Preferably, the device management means include 
■ storage means for storing product owner identification 
data, identifying product owner participants responsible 
for managing products associated with devices managed by 
10 the device manager participant, and card acceptor 

identification data, identifying card acceptors using 
devices managed by the device manager participant. 

Preferably, the product management means includes 
storage means arranged to store card manager identification 
15 data identifying card managers managing cards supporting 
products managed by the product owner part icipant . 

The product management means may also store card 
holder identification data, identifying card holders 
holding cards having products managed by the product owner 
20 participant, and card acceptor identification data, 
identifying card acceptors having devices supporting 
products managed by the product owner participant. 

Preferably, the card management means is arranged to 
store product owner identification data identifying product 
25 owner participants responsible for managing products 
associated with cards managed by the card manager 
participant. The card management means may also store card 
holder identification data, identifying card holders 
holding cards managed by the card managed participant. 
30 Preferably, each of the management means also stores 

links to the management means of other participants. 

In each management means, a database may store the 
required data. 

Note that in each case identification data may not be 
35 the actual identity of the entity. For example, the 
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product owner may not need necessarily to have the name of 
the card holder who has a product of the product owner. It 
may be sufficient to have an ID number, without knowing the 
actual name of the card holder. It may only be necessary 

5 for the card manager to know the actual identity of the 

card holder. In many cases a card holder will not wish to 
• provide their identity to more entities than necessary. 
The present system enables products to be provided to a 
card holder without the card holder having necessarily to 

10 provide his identity to a product owner. 

Usually, it will be required that the card managers 
have an actual identity of the card holder and that the 
device managers have an actual identity of the card 
acceptor. Other than this, actual identities do not 

15 necessarily need to be provided to any other participant. 

Any product owner must have a relationship with a 
cardholder. The relationship with the cardholder need not 
be direct. It could be by way of a card manager. What the 
product owner requires in the relationship with the 

20 cardholder is the right type of product data to enable 

management of the product. This can be any data that the 
product owner requires from the cardholder, as well as any 
data that the product owner provides to the cardholder. It 
may be a product transaction, the name and address of the 

25 cardholder, a card application for a product, a unique 
identifier of the card (e.g., a card number) and 
cardholder, or any other information. 

Any product owner must have a relationship with a card 
accepter. The relationship with the card accepter need not 

30 be direct. It could be by way of a device manager. What 
the .product owner requires in the relationship with the 
card accepter is the right type of product data to enable 
management of the product. This can be any data that the 
product owner requires from the card accepter, as well as 

35 any data that the product owner provides to the card 
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accepter. It may be a product transaction, the name and 
address of the card accepter, a device application for a 
product, a unique identifier of the device (e.g., a device 
number) and card accepter, or any other information. 
5 The relationship with the card accepter and the 

cardholder may be implemented dynamically. That is, the 
relationship may occur only when the card accepter and 
cardholder come to operate the product e.g., the product 
may be loaded by the card acceptor and cardholder at any 
10 time. 

To manage the cardholder (referred to by the product 
owner as the "product-holder") relationship, data such as 
the identity of the cardholder will usually be required by 
the product owner. The identity need not , be an actual 

15 identity but may merely be an identification number. In 
some cases even identity information may not be necessary 
i.e., it may be enough for the product owner to receive 
transaction data indicating that there is a card holder. 
Again, the relationship with the cardholder may be indirect 

20 and any information on the cardholder could be provided by 
other parties in the system e.g., a card manager. 

To manage the card accepter (referred to by the 
product owner as the "product accepter") relationship, data 
such as the identity of the card accepter will usually be 

25 required by the product owner. The identity need not be an 
actual identity but may merely be an identification number. 
In some cases even identity information may not be 
necessary i.e., it may sufficient merely to receive 
transaction information from the card acceptor so that the 

30 product owner is aware that there is a card acceptor. 
Again, the relationship with the card accepter may be 
indirect and any information on the card accepter could be 
provided by other parties in the system e.g., a device 
manager . 
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Separation out of product management from other 
aspects of card management provides a number of advantages. 
Any card and/or device product can be managed separately 
from all other aspects of the card- and/or device-related 
environment. Thus, the role of the product owner is 
simplified (management of the product only), such that the 
product owner - need not be concerned with, for example, 
the provision and management of cards and - devices 
required to support their product. This also results in 
less effort on the part of card managers and device 
managers to support the products of a product owner. For 
example, a chain of restaurants may wish to manage a 
loyalty scheme, where they would be the product owner of 
the loyalty scheme. Their product management system would 
only need to be able to manage the information required to 
manage the loyalty scheme, not the broader aspects of card 
and/or device management unrelated to their loyalty scheme. 
These other aspects of card and device management will be 
conducted by card manager and device managers that agree to 
20 support the restaurant chain's product. 

Preferably, the card management means manages aspects 
of the card-related environment that are associated with 
the card manager. The card manager management system(s) 
should preferably be able to uniquely identify each card it 
manages, maintain data relating to that card, and share 
such data with product owners and device managers. 

Preferably the device management means manages aspects 
of the device-related environment that are associated with 
the device manager. The device manager management 
system(s) should preferably must be able to uniquely 
identify each device it manages, maintain data relating to 
that device, and share such data with product owners and 
card managers. 

With the management system(s) of the present 
35 invention, therefore, an entity that wishes to be involved 
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in any one aspect of the tripartite card environment 
conceived by the applicant (product management, card 
management and device management) will require only the 
appropriate part of the system which relates to management 
5 of the aspect of the environment that they are responsible 
for, together with the message management means, enabling 
communications between the management systems of different 
entities in a tripartite environment. 

The product owner, for example, thus manages the 

10 product in isolation from all the other tasks. Aspects of 
the product may be updated (e.g., a new version of the 
product application on the card) through the product 
management means in a tripartite environment, thus avoiding 
the need for that entity to also have a card- and/or device 

15 management means. 

This serves to illustrate an important aspect of the 
present invention. In the prior art systems discussed in 
the preamble where a third party operates a product such as 
a loyalty scheme as a secondary product receiving data from 

20 a system which has been designed to operate a primary 

product, the loyalty product owner is not really a party to 
the management system at all. The prior art environment is 
dual role or single role environment, and the third party 
depends upon the parties to the primary product for any 

25 information, transactional information and to make any 
amendments to the product. Where the product is on the 
card or in the device, it is the primary participants who 
must make amendments to the product application. 

In the present invention, the product owner is 

30 preferably able to affect control over the product. For 
example, where the product application exist either on a 
device or on a card (such as a smart card) or on both, the 
product owner may be able to download an updated 
application via the management system, perhaps- without any 

35 intervention of any of the other management participants in 



17 - 



10 



15 



the system. Transaction data created in relation to the 
product may be routed to the product owner via the message 
management means of the other participants in the system, 
without processing by the management modules of the other 
participants. The management system of the present 
invention, therefore, preferably facilitates enabling the 
product holder to communicate directly with the product 
e.g., to put information on the product or to receive 
information from the product. This cannot be done in the 
prior art by a third party operator who is not directly 
involved in the prior art dual role or single role 
environment. 

Further, with a management system in accordance with 
the present invention, the replacement of cards and devices 
that have been lost, stolen, damaged, destroyed, - re- 
assigned or the like becomes much simpler. A card or 
device may include a number of products which are known by 
the management system (s) of the card manager and the device 
manager, which also maintains non-product specific data. 
The management system) s) of the card manager and device 
manager may also maintain product specific data provided by 
each product owner, or may maintain links to each product 
owner's management system such that this product-specific 
data can be obtained. In this way, a card manager or 
25 device manager may obtain data from the management 

system(s) of product owners that, together with data 
maintained on their own management system, will enable a 
card or device to be reconstructed and replaced. 

The provision and management of multi-product cards 
and devices becomes simpler with a management system in 
accordance with the present invention. If a product owner 
wishes to deploy a product onto a card or device, all they 
need do is obtain the product management system and message 
management package, and establish a relationship with a 
card manager and device manager for that product. The card 
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manager can then assist the product owner to deploy the 
product on their cards, and the device manager can assist 
the product owner to deploy the product on their devices. 
Once the product is operational, the device manager and 
5 card manager can configure their management systems to 
manage transactions facilitated by the product. For 
example, the device manager's management system may route 
product transactions received from their devices directly 
to the product owner' s management system, and the card 

10 managers' management system may inform the product owners' 
management system of any change of address details advised 
by the cardholder. 

The security and privacy aspects of the system of the 
present invention are also particularly advantageous. 

15 Cardholders are often reluctant to give too many personal 
details to certain entities. With the present invention, 
all that the product management system requires is 
sufficient information to be able to manage the product. 
The personal identity of a cardholder may not be required. 

20 Such aspects can be left to the card manager. If the card 
manager is a reputable bank, therefore, for example, the 
product owner may "trust" the bank to ensure the bona fides 
of the cardholder, and thus would not require this 
information themselves. This is advantageous for the 

25 cardholder as it limits the number of entities that require 
detailed personal information, but still enables the 
cardholder to obtain access to multiple products, thus 
protecting personal privacy. If the product owner must 
communicate with the cardholder, this can be achieved 

30 through the card manager who can link the unique identifier 
of the cardholder maintained by the product owner with the 
personal information of the product owner, and then 
communicate directly with the latter. 

Customer service is also facilitated by the present 

35 system. The cardholder may need only a single contact 
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(usually the card manager) if a product is not operating to 
satisfaction. A cardholder complains to the card manager 
who may be able to process the complaint themselves or who 
will be able to pass it on straight away to the product 
owner (or other relevant party) via the management system. 

The management system of the present invention also 
preferably includes interface means to interface the 
management system with external systems. This interface 
means is preferably provided in the form of software 
modules which the applicant terms "business modules 7 ' which 
operate a processing means to interface with a desired 
external system. For example, a product owner may already 
have or may wish to design their own external system for 
processing aspects of a product. A business, module 
therefore provides a link between the external system and 
the management system and may convert the data being 
received by the management system into a form which is 
usable by the product owners external system. Modules may 
also interface to legacy systems, so that the management 
system of the present invention is able to fit in with 
existing systems. 

The present invention further provides a product 
management system, comprising a product management means 
which enables a product owner participant to perform a 
product management role alone, without managing cards and 
without managing devices, wherein the system is arranged to 
facilitate the product owner participant to directly affect 
control of a product associated with a card or device. 

By "facilitate" is meant that the system gives a 
mechanism by which data can be communicated directly 
between the product holder and the product associated with 
the card or device. The product may be on the card or on 
the device in the sense that software is resting on the 
card or device relating to the product. The card or device 
may be considered in terms of "real estate" e.g. the smart 
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card may include a number of storage locations which the 
card manager can "let" to product owners. The card manager 
will provide a u key" to enable the product owner to have 
access to a secure location on the card and the product 
5 owner could in fact provide their own key to prevent 

interference with the product on the card. This cannot be 
done by present multiple product arrangements, wherein 
primary processing is required by a card manager or device 
manager before a product owner, such as a loyalty points 

10 owner, can manage the product. 

The present invention further provides a card 
management system, including a card management means which 
enables a card manager participant to perform a card 
management role alone, without managing products associated 

15 with a card and without managing devices. 

The present invention further provides a device 
management system, including a device management means 
which enables a device manager participant to perform a 
device management role alone, without managing products 

20 associated with a card and without managing cards. 

The present invention further provides a card, device 
and product management system, including a plurality of 
service processing means, each service processing means 
enabling a participant to the system to carry out at least 

25 one of card, device and product management, and a message 

management means provided to each participant in the system 
and arranged to act as a communications interface routing 
message data between each of the service processing means 
and between cards and devices, to enable a network of 

30 service processing means and a plurality of participants to 
interface to carry out card, device and product management. 

The present invention further provides a card, device 
and product management system including a network 
comprising a plurality of nodes, each node comprising a 

35 service processing means enabling a system participant to 
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carry out at least one of card, device and product 
management, and a message management means arranged to act 
as a communications interface routing message data between 
the service processing means of each node and between cards 

5 and devices. 

The present invention further provides a method of 
managing cards, devices and products, comprising the steps 
of defining a tripartite environment for card management, 
the card management tripartite environment comprising; 

10 a card manager participant responsible for managing 

non-product specific card operations; 

a device manager participant responsible for managing 
devices for accepting cards and for carrying out product 
transactions; and 

l6 a product manager participants, responsible for the 

management of product-related aspects of the card 
environment, wherein the device manager participant, card 
management participant and product manager participant may 
be separate entities. 

20 The present invention further provides a method of 

managing products, comprising the steps of defining a 
product manager participant, responsible for the management 
of products alone, without managing cards and without 
managing devices, and facilitating the product manager 

25 participant to directly affect control of a product 
associated with a card or device. 

The present invention further provides a method of 
managing cards, comprising the steps of defining a card 
manager participant whose role is to perform management of 

30 cards alone, without managing products associated with a 
card ,and without managing devices. 

The present invention further provides a method of 
managing devices, comprising the steps of defining a device 
manager participant whose role is to perform management of 
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devices alone, without managing products associated with a 
card and without managing cards. 

Features and advantages of the present invention will 
become apparent from the following description of an 
5 embodiment thereof, by way of example only, with reference 
to the accompanying drawings, in which: 

Fig. 1 is a schematic diagram of a present card- 
related environment ; 

Fig. 2 is a schematic diagram of a card-related 
10 environment facilitated by the card management system of 
the present invention; 

Fig. 3 is a block diagram of a system architecture of 
a card management system in accordance with an embodiment 
of the present invention; 
15 Fig. 4 is a schematic diagram giving an example of an 

overall linked system including entities running a 
plurality of card management systems in accordance with 
embodiments of the present invention, for managing 
transactions for multiple product cards; 
20 Fig. 5 is an illustration of application of a 

management system in accordance with an embodiment of the 
present invention; 

Fig. 6 is a schematic diagram illustrating processing 
of a compound transaction in a management system in 
25 accordance with an embodiment of the present invention; 

Fig. 7 is a schematic diagram illustrating a smart 
card reconstruction process utilising a management system 
in accordance with an embodiment of the present invention; 

Fig. 8 is a schematic diagram illustrating an 
30 application download to a smart card utilising a management 
syste.m in accordance with the present invention, and 

Fig. 9 is a schematic diagram illustrating a process 
for deleting an application from a smart card utilising a 
management system in accordance with an embodiment of the 
35 present invention. 
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Figure 1 shows the current environment for management 

of card products. 

The environment includes a card issuer 1. The card 
issuer is responsible for issuing and managing a card 2 
5 (perhaps by way of a separate card-manufacturing bureau) to 
a cardholder 3. The card issuer may be a bank or other 
financial institution that wishes to issue cardholders 
cards having a credit card product, for example. The card 
issuer would require details of the identity of the 
10 cardholder, address, credit rating, etc. 

The environment also includes a transaction acquirer 
4. The transaction acquirer is responsible for deploying 
and managing devices 5 (perhaps by way of a third party 
distributor) to a card accepter 6. The transaction 
15 acquirer may be a bank or other organisation that wishes to 
deploy devices to card accepters who support a credit card 
product, for example. The transaction acquirer would 
require details of the identity of the card accepter, 
address, bank account details, etc. 
20 Traditionally, dedicated computer systems are used to 

manage the card product in the current environment. These 
systems are subject to the problems discussed in the 
preamble of this specification. 

Referring to figure 2, a modified environment is shown 
25 which is facilitated by the card management system in a 

preferred embodiment of the present invention. In addition 
to the card manager 1 (the renamed card issuer) and device 
manager 4 (renamed transaction acquirer), there is a 
further entity, product owner 7. The product owner 7 is 
30 responsible for management of aspects of the environment 

that relates to a particular product supported by the card 
2 and the device 5. The product owner is only responsible 
for the product. The product owner is not responsible for 
other aspects of the card and device environment that are 
35 not specifically product- related, such as issuing and 
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managing cards and deploying and managing devices. A 
product owner needs only information on a card, device, 
cardholder and card accepter that is required to operate 
the product. The product owner 7 will have relationships 
5 with card accepters and card holders who support the 
product . 

The product owner, card manager, and device manager 
functions may be carried out by one or more entities, which 
may in turn perform one of more functions. In this way, 
10 many scenarios are supported. For example, one entity may 
only perform the product owner function, another entity may 
perform the card manager and product owner function, a 
third entity may perform all three functions, whilst a 
final entity may perform only the device management 
15 function . 

The architecture of the management system in 
accordance with an embodiment of the present invention is 
illustrated schematically in figure 3. The management 
system comprises a message management module 10, card 
20 management module 11, device management module 12, and 
product management module 13. 

The message management module which is arranged to 
receive message-data (e.g., from devices) and forward the 
message data onto the appropriate service management module 
25 11, 12, 13. . Similarly, it can receive message data from 
the management module 11, 12, 13 and forward them out of 
the system or to other management modules. 

Each of the management system modules includes 
functionality that enables management of cards (card 
30 management module 11), devices (device management module 
12) and products (product management module 13) . 

The system also comprises one or more business modules 
14. These modules encapsulate the functionality required 
to meet a particular business need of one or more entities 
35 participating in a card environment utilising a management 
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system in accordance with the present invention. The 
business modules provide extensions and/or constraints to 
the management system in order to support specific business 
requirements. For example, they may support the technical 

5 implementation of the MULTOS card platform, support an 

interface to a legacy database system, support transaction 
processing specific to a particular product, or manage 
transactions received from a particular device. 

Each of the card 11, device 12 and product management 

10 13 modules (the service modules) include relational 

databases and processing means to provide the following: 

Product Management Module 

1. Provide products for card holders (Card, holder product 
15 to Product owner) and Card Acceptors (in the form of a Card 

Acceptor product to a Product Acceptor)-. 

2. Establishment of products within Card Manager/Device 
Manager constraints. 

3. Process product transactions. 

20 4. management of relationships with suppliers, Card 

holders/Card acceptors and Card Managers/Device managers. 

5. Supports management of product life cycle (including 
product data and applications) and the management of 
supported device/card relationships per Product (including 

25 the relationships with Card Managers and Device Managers) . 

6. Manage card products and related information. 

7. Product specifications. Specifies card and device 
applications, compatible card and device platforms, 
required memory of cards/devices, parameters and data 

30 requirements. 

8. Product relationships e.g. relationships between 
different products . 

9. Product parameters/configuration. 

10. Primary product certificates, cryptography. 
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11. Card Manager and Device Manager information. Multiple 
card managers and device managers may support product . 

12. Links to or data from the card management module for 
card holders using the product. 

5 13. Device management links. Links to or data from the 
device management module for card acceptors supporting the 
product . 

14. Transaction data may be required to be mirrored for 
reconstruction. 
10 15. Card/device application. 

16. Application provision. Dynamic downloading of 
applications to cards. 



Device Management Module 
15 1. Establish and manage devices used by card acceptors. 

2. Establishment of devices at card acceptor locations. 

3. Deployment of products from product owners. 

4. Management of relationships with suppliers,, card 
acceptors and product owners. 

20 5. Ordering of devices from vendors. 

6. Maintenance and management of device inventories and 
devices installed (including data & applications on 
devices ) . 

7. Management of supported product relationships per 
25 device (including the relationships with the product 

owners) . 

8. Device specification data. To define device 
maintenance/management processes - provides details about 
capacity for applications, etc. 

30 9. Device parameters/configuration data required for 
device installation reconstruction processes. Defines 
device manager specific configuration of device data. 

10. Primary device certificates, keys - cryptography. 

11. Device product applications, links. Product 

35 applications may be managed by the transaction processor 
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but for device reconstruction processes at least links are 
maintained. 

12. Card acceptor data e.g. conduct details, full title, 
demographic information, etc. 
5 13. Card acceptor /Device relationships. Multiple device 
may be linked to same card acceptor. 

14. Card acceptor establishment e.g. through manual data 
entry, electronic file import. 

15. Card acceptor communications. Statements, etc. 

10 16. Application distribution. Keep track and distribute 
applications to devices and card applications to be 
distributed to smart cards. 

17. Device utilisation provides device manager with tools 
to specify the data to be included on the device. 
15 18. Device update reconfiguration update and reconfigure 
device. 

19. General device/card acceptor management. Fees, 
management, reports. 

20 Card Management Module 

1. Issue and manage cards used by cardholders. 

2. Issuing of cards to carholders (including re- 
issuing/reconstruction) 

3. Deployment of products from product owners. 

25 4. Management of relationships with Suppliers, Card 
holders and Product owners. 

5. Ordering of cards from vendors. 

6. Management of card stock and cards issued (including 
data and applications on card) 

30 7. Management of supported product relationships per card 
(including the relationships with the product owner) . 
8. Card holder Data. All card holder related data is 
required to be captured and maintained by the card 
management module e.g. card holders name, contact details, 
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identif ication references, demographic information, market 
research findings and diary notes. 

9. Card/card holder relationships (relationship links 
required for many to many relationships between cards and 

5 card holders. Multiple card holders may be linked to the 
same group (e.g. family cards) - multiple cards to same 
Card holder (company, corporation cards). 

10. Card specification data, card platform issued, memory 
capacity, types of memory, for capacity of applications. 

10 11. Card parameters/configuration data - for card 

production/updating/reconstruction processes . Specify how 
card memory space is used and data/applications downloaded 
onto card and defines general card issuer specific 
configuration of the card data (this does not include 

15 product specific data/applications. 
12. Personalisation data for card 

production/reconstruction processes specifies the card 
holder data provided on the card, which may be number of 
cardholder data. 
20 13. Primary card certificates/keys (cryptography) 

14. Card product applications /links - maintains links to 
product manager to enable reconstruction of card. 

15. Card holder establishment, through manual data entry, 
electronic file import, etc. 

25 16. Card holder communications e.g. event dates/time dates 
such as card issuance. 

17. Card production/issuance provides tools for card 
manager to specify data to be included on cards and provide 
for unique ID of card. 
30 18. Card updating/reconstruction - facility to update 

reconstruct specified card or range of cards - may require 
the need for regular "reconciliations" with card in on-line 
environment. 
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19. General card management. Card/card holder requirement 
(determining reports, etc) participants related 
requirements (fees payable, renewable). 

The message management module enables the following 
functions : 

Message management Module 

1. Manages message and data flows for and between the 
service and business modules. 

2. Captures formatting, routing and logging of 
transact ions /mess ages . 

3. Sending and receiving of transactions/messages within 
and between the connected management systems as well as 
external systems devices and cards. 

4. Cryptographic processing of data, including 
authentication . 

5. Logging of billable events and support for activity 
based and generic fees. 

6. Production of standard and ad hoc reports. 

7. Administration of systems, including installation, 
configurations, access control, monitoring, recovering and 
archiving . 

8. Compliance with generally accepted standards, 
performance and operational criteria, including 
localisation of implementation. 

9. Manage and route messages to/from interconnected 
systems, devices and cards. 

10. Manage communications to/from individuals and 
organisations (e.g. customer inquiries, letters). 

11. Produce information representing fees. 

12. Perform system administration tasks (e.g. installing 
and uninstalling configuring, performance monitoring, 
logging, notifying users, detecting and analysing 
anomalies, backing up and restoring, archiving and 
retrieving . 
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IS. Support appropriate access control, physical security 
and cryptographic processing (e.g. authentication, 
encryption ) . 

14 . Record and review the current and historical state of 
5 the system (e.g. for audit purposes). 

15. Convert from transaction format to the internal 
transaction format of the service module or external 
system. 

16. Capturing transactions and writing them to a log sheet 
10 for reconciliation, auditing, etc. 

17. Transaction splitting. Some transactions received may 
be compound transactions (same transaction applies to 
multiple products or applications) and are required to be 
split into two or more atomic transactions - transactions 

15 must be routed as early in the transaction chain as 
possible to ensure highest data privacy possible. 

For a particular operator of the management system in 
accordance with the present invention, they may have one, 
two or all of the three management modules 11, 12, 13, 

20 depending upon their function as an entity in the 

environment. Referring to figure 4, for example, entity 
one is an organisation that wishes to provide and run 
certain products. All they require of the system is the 
foundation module and the product management module, as 

25 well as any business modules that may be needed in order to 
support particular business functionality. Entity two is a 
card and device manager, whilst entity three is a card 
manager, device manager and also a product owner. 

Each of the management systems of entity one, entity 

30 two and entity three may be connected to support various 
products. For example, a product owner may establish a 
commercial relationship with entity one and/or entity two 
as the card manager and/or device manager for their 
particular product . 
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In operation, a cardholder 1 who requires an available 
product may seek the' product from the product owner. The 
product may be provided as a software application 
downloaded via a device 5. The cardholder could in fact 

5 interact directly with the device to request the product, 
provide any details that may be required (if they cannot 
already be provided from the details that the card manager 
has on the cardholder) . The product can then be entered on 
the card holders card. 

10 Fig. 5 is an illustration of an example configuration 

of the use of management systems in accordance with the 
present invention. Two participants are illustrated. 
Participant "A" is a bank or other financial institution 
that operates a credit card product. They, run a management 

15 system in accordance with the present invention, including 
message management module 20, card management module 21, 
device management module 22 and product management module 
23. Business management module a 24 and business 
management module b 25 are also provided. Participant A 

20 not only manages the credit card product using product 

management module 23, but also manages devices 26 and cards 
27, utilising device management module 22 and card 
management module 21, respectively.. 

Participant M B" is an airline which owns a loyalty 

25 product. They have a system in accordance with the present 
invention comprising a message management module 28, a 
product management module 29, business management module c 
30 and a loyalty system application 31. The loyalty system 
application 31 is an application designed specifically for 

30 participant B, for processing its loyalty system 
transactions . 

Card holder 32 possesses a card 27 which supports both 
the credit card product of participant A and the loyalty 
product of participant B. 
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Card holder 32 purchases goods from card acceptor 33. 
In order to pay for the goods the cardholder uses the 
credit card product on the card 27 via device 26. Message 
data 34 generated by the device 26 is transferred directly 
5 to the message management module 20 participant A. Message 
management module 20 routes the message data to the device 
management module 22. The device management module 
determines that message data relates to a transaction which 
is associated with their credit card product and also with 

10 the loyalty product of participant B. The device 

management module 22 operates to break down the transaction 
data into message data for the participant B and also 
message data for the product management module 23 of 
participant A. Message data for the product management 

15 module 23 is routed via the message management means 20 to 
the product management module 23. The credit transaction 
is an "on us" transaction and the product management module 
23 determines that the participant A is also the card 
manager 21. Appropriate transaction information may be 

20 provided to the card management module 21 via the message 
management module 20 and also to an external credit card 
processing system 34 after having been converted by 
business module a 24 into an appropriate (different) form 
required for the credit card processing external system 34. 

25 The system 34 may be a legacy system which was already in 
place at participant A before installation of the 
management system of the present invention. 

The message data intended for the participant B is 
first of all routed by business . management module b 25, for 

30 appropriate cryptographic conversion. Participant B 

requires that this cryptographic processing be carried out 
for security purposes. After processing by the business 
management module b 25, the encrypted message. data is 
transmitted via the message management module 20 to the 

35 message management module 28 of participant B. Message 
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management module 28 passes on the message data to product 
management module 29. The product management module 29 
calculates loyalty points, for example. In this particular 
case,' participant B has a separate loyalty product system 
5 31 that needs to be updated with the loyalty points. 

Further message data generated by the product management 
module 29 and including the loyalty point information is 
converted via business management module c 30 to an 
appropriate format for the loyalty point system 31 and 
10 passed to the loyalty point system 31 via the message 
management module 28. 

Another example of the utility of the management 
system of the present invention is in the handling of 
compound transactions. 
15 a compound transaction is a single transaction which 

applies to multiple applications managed by the same or 
different processing systems/management systems of the 
present invention. For instance, a credit product 
transaction with an attached loyalty product may generate 
20 one transaction between smart card and device; however, the 
atomic transactions for the credit product and the loyalty 
product may be routed to different systems. Compound 
transactions occur each time multiple applications generate 
a compound transaction during the interaction between smart 
25 card and devices. 

Figure 6 illustrates the transaction flow for a 
compound transaction. The steps involved are described in 
detail below. 

1. During an interaction between smart card 40 and device 
30 41, multiple applications generate a compound transaction. 

2. Periodically the device dials into the Device 
Management 42 to upload all transactions, which are logged 
by the Message Management module 4 3 of the .Device 
Management 42. 
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3. The Device Management 42 applies pre-defined rules to 
the logged transactions. A compound transaction rule 
generates multiple atomic transactions destined for 
multiple management systems in accordance with the present 

5 invention or legacy systems. 

4 . The Device Management 42 transmits the atomic 
transactions to one or more Product Management modules, 44, 
45 and/or to one or more legacy systems 46, for further 
processing . 

10 5. The Device Management may optionally transmit an 
advice to one or more Card Management systems to advise 
altered smart card data or applications. 
Other possibilities are: 

1. Multiple applications operating concurrently may 

15 generate an atomic transaction each, such that no compound 
transactions occur . 

2. A compound transaction may be divided into its atomic 
transactions in the device prior to a periodic batch 
transmission to the Device Management. 

20 The process of recreating smart cards may become 

necessary when cardholders advise the card issuer that the 
smart cards are lost or stolen. The recreation of the 
smart card involves blocking the lost/stolen card, 
accumulating the applications and data from the Card 

25 Management system, and personalising a new smart card. 

The Card Management may only recreate the smart card' s 
applications and data for which the Card Management has 
received explicit permission from the cardholder. The 
cardholder is responsible for recreating private data. For 

30 instance, cryptographic keys may only be obtained by the 
cardholder or by the Card Management with explicit 
permission from the cardholder, possible through a request 
to the Product Management module which may .request the 
cardholder keys for an application from the CA. 
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Figures 7 illustrates the transaction flow for the 
recreation of a smart card. The steps involved are 
described in detail below. 

'The steps of the transaction flow may be described as 

follows : 

1. The cardholder 50 requests a smart card recreation 
from the card issuer 51, and provides card issuer 51 with 
desired permission for the reconstruction process. 

2. The card issuer instructs the Card Management module 
52 to block the previous card and schedule the 
reconstruction process, and requests a smart card 
reconstruction . 

3. The Card Management 52 generates a new card number, 
assimilates the cardholder data, the card applications 
references and requests the applications and possibly the 
permissive card data (should the card data not reside 
within the Card Management module) from one or more Product 
Management modules 53 and/or one or more legacy systems 54 
referred to in the card application references. 

4. The Product Management modules (s) 53 and/or legacy 
system (s) 54 review the permissions, may request the 
appropriate data from other sources, e.g. CA, update the 
appropriate databases with the new card number and transmit 
the applications and possibly the card data to the Card 
Management module 52. 

5. The Card Management module 52 generates a 
personalisation file with all the assimilated applications 
and data. The personalisation file may be processed in the 
form of a report by an independent card personalisation 
machine 55 and the card 56 submitted to the cardholder 50. 
Variations : 

1. The card Management may request a smart card or a 
range of smart cards to be reconstructed, e.g. the expiry 
date is printed on the card face. 
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One of the major advantages of the management system 
in accordance with the present invention is. that it enables 
dynamic loading and unloading of product applications from 
smart cards and/or devices after issuance of the smart card 
5 or installation of the device. 

The dynamic application load transfers an application 
to a smart card or device, to ensure that new applications 
may be loaded onto smart cards after the cards have been 
issued, and loaded onto the devices after they have been 
10 installed. The application load transaction occurs upon 

request, the request may be issued by the management system 
modules or by the cardholder or card acceptor. 

Figure 8 illustrates one of the possible transaction 
flows for an application load transaction to smart cards. 
15 The steps involved in this variation are described in 
detail below. 

The step of the transaction flow to facilitate 
application loading onto smart cards may be described as 
follows : 

20 1. During the interaction between smart card 60 and 
device 61, the device offers the smart card 60 an 
application that is not resident on the smart card 60. 

(a) The smart card 60 may verify that the application 
may legally reside on the card manager's card (e.g. 

25 ascertaining that an agreement is in place between card 
manager and device manager for this application) . 

2. The cardholder agrees to load the application onto the 
smart card 60, the smart card 60 requests the device 61 to 
provide the application for the smart card 60 to load into 

30 its memory. 

3. The device dials into the Device Management 62 of the 
management system of the present invention. 

4. The Device Management 62 sends an application request 
to the Product Management 63. 
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(a) Should the smart card- 60 and device 61 not be 
able to ascertain the legality of the application on the 
smart card 60, the verification may be required between 
Device Management 62 and Card Management 64, prior to the 
5 application request being submitted to the Product 
Management 63. Also, if the application has a value 
associated with the application, the Device Management 62 
may ascertain that the smart card 60 has not been blocked. 

5. The Product Management 63 provides the requested 
10 application to the Device Management 62. 

6. The Device Management 62 provides the requested 
application to the device 61. 

7. The device 61 discontinues the on-line link to the 
Device Management 62 and provides the smart • card 60 with 

15 the requested application. 

8. The smart card 60 installs the application in its 
memory . 

9. The smart card 60 may send an advice of the successful 
loading to the device 61 for batch upload to the Device 

20 Management 62 for distribution to the requesting 

participant. This advice may be necessary for mission 
critical application, whilst other products or Card 
Management 64 may not require the advice. The Device 
Management 62 may transmit the advice to 

25 • Card Management 64 

• Product Management 63 

• both 

The Dynamic Application Load for devices may be facilitated 
in a similar manner with the instruction for the load 
30 originating either from the device, the Device Management 
module or the Product Management module. 

Note that the device management 62, product management 
63 and card management 64 may belong to the same entity or 
separate entities . 
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Variations 

'Other possibilities for application loads to smart 
cards are: 

5 1. The cardholder requests by phone that the application 
be loaded onto the smart card, e.g. the next time the smart 
card is on-line for another transaction. The Product 
Management will schedule the load and request the Device 
Management to provide the device with the application upon 
10 request, e.g. when the smart card is on-line. 

2. The Product Management arranges an agreement with the 
Card Management to provide all the smart cards managed by 
the Card Management with an application. Either the Card 
Management or the Product Management instructs the Device 

15 Management to: 

(a) provide all the devices managed by the Device 
Management with the application upon request, e.g. when the 
smart cards are next on-line; 

(b) provide all the devices managed by the Device 
20 Management with the application the next time the devices 

are on-line, such that the application loading may be 
facilitated off-line when the smart cards interact with the 
devices . 

3. The Card Management instructs the Device Management to 
25 load applications onto a range of smart cards either: 

(a) the next time the smart cards are on-line for a 
transaction ; 

(b) by pre-loading the application onto devices for 
off-line application loading. 

30 Other possibilities for application loads to devices are: 
1. : The device requests on-line that an application be 
loaded, e.g. to process a transaction with a smart card 
which holds an unknown application. The Device Management 
requests the application from one or more Product 

35 Management modules. The application is loaded onto the 
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device in a similar fashion to the smart card application 
load. Once the application is installed in. the device, the 
transaction with the smart card may proceed. 

2. The Device Management requests the device applications 
from the Product Management module (s) and transfers the 
applications to a range/all devices for installation during, 
the next interaction with the devices. 

3. The Product Management requests the Device Management 
to provide the devices with applications during the next 
interaction with the devices. 

The dynamic application unload deletes an application 
from a smart card 70n or device 71, to ensure that 
applications may be unloaded from smart cards after the 
cards have been issued, and unloaded from the. devices after 
they have been installed. The application unload 
transaction may occur automatically (e.g. single use 
coupons) or upon request, the request may be issued by the 
modules of the management system of the present invention 
or by the cardholder or card acceptor. 

Figure 9 illustrates the transaction flow for an 
unload transaction. . The steps involved are described in 
detail below. 

The steps of the transaction flow to facilitate 
application unloading from smart cards may be described as 
follows : 

1. The Card Management 72 may request the Device 
Management 73 to delete an application from a range of 
smart cards managed by the Card Management 73, 

(a) the next time the device 71 in on-line for a 
transaction with one of the smart cards 70 within the 
range; 

(b) broadcast the request to the devices 71 the next 
time the devices 71 are on-line for an interaction with the 
Device Management 73 such that the unload request may be 
communicated to the smart card 70 off-line during a 
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transaction interaction (this mode may be necessary if the 
Card Management 71 discontinues the support . of the 
application or a cardholder abuses the application) . 

2. During the interact ion between smart card 70 and 
5 devices 71. 

(a) and the device has to dial-in to the Device 
Management 73 to complete the transaction, the Device 
Management 73 may request the device 71 to communicate the 
unload request to the smart card 70 as part of the response 

10 to the device 71. The device 71 discontinues the 

communication with the Device Management 73, completes the 
transaction, and communicates the unload request to the 
smart card 70 . 

(b) communicates the broadcasted unload request to 
15 the smart card 70. 

3. The smart card 70 deletes the application from its 
memory, with an optional advice to the device 71 tat the 
application ahs been deleted. The advice may be uploaded 
to the Device Management 73 during the next interaction, 

20 which may be transmitted to the Card Management 72 and the 
Product 73 Management modules. 

The Dynamic Application Unload for devices may be 
facilitated in a similar manner with the instruction for 
the load originating either from the device, the Device 
25 Management module or the Product Management module. 

Other possibilities for application unloads to smart 
cards and/or devices are: 

1. The Product Management may request the Device 
Management to unload an application from all smart cards 

30 and/or all devices, e.g. a discontinued application. 

2. : The smart card may delete the application from its 
memory after a single use of the application, e.g. single 
use coupons. 
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3. The device may request the smart card to delete the 
application from its memory after a single. use of the 
application, e.g. single use coupons. 

4 . ' The Device Management may request the device that an 
5 application that is no longer supported by the Device 

Management be deleted from the. device's memory. 

Implementation of a management system in accordance 
with the present invention can enable methods of operating 
and making available products that are not presently 

10 practical. 

For example, card managers and device managers 
operating the system may publish a set of "standards" for 
compliance with their systems. Product owners complying 
with those standards could then offer, products for use with 

15 the cards and devices managed by the card manager and 

device manager. There would be no need for any complex 
negotiations to establish the parameters of the 
relationship between the product owner, device manager and 
card manager. The product owner would merely have to 

20 arrange his product to comply with the standards and then 
make the product available to the card manager and device 
manager, who would in turn make the product available to 
the card holder. An already fully compliant product is 
offered for use with the systems. 

25 It will be appreciated by persons skilled in the art 

that numerous variations and/or modifications may be made 
to the invention as shown in the specific embodiments 
without departing from the spirit or scope of the invention 
as broadly described. The present embodiments are, 

30 therefore, to be considered in all respects as illustrative 
and not restrictive. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 



'1. A card, device and product management system, 
including a card management means which enables a card 
5 manager participant to perform a card management role 

alone, without managing products associated with a card and 
without managing devices; 

a device management means which enables a device 
manager participant to perform a device management role 
10 alone, without managing products associated with the card 
and without managing cards; and 

a product management means, which enables a product 
owner participant to perform a product management role 
alone, without managing cards and without managing devices, 
15 whereby all three roles can be performed by separate 
entities . 

2. A system in accordance with claim 1, further 
comprising a message management means arranged to manage 
the routing of message data between cards, devices and a 

20 card, device and product management system. 

3. A system in accordance with claim 2, wherein the 
message management means is also arranged to act as a 
communication' s interface routing message data between the 
card management means, device management means and product 

25 management means. 

4. A system in accordance with claim 2 or claim 3, 
the message management means also being arranged to manage 
the routing of message data to external systems. 

5. A system in accordance with any one of claims 2 

30 to 4, wherein each one of the card management means, device 
management means and product management means is provided 
with an associated message management means. 

6. A system in accordance with any one of the 
preceding claims, wherein the system is arranged so that 

35 the product management means is arranged to facilitate the 
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product owner participant to directly affect control of a 
product associated with a card or device, without 
intervention of any of the other participants. 

'7. A system in accordance with claim 6, wherein the 
control of the product involves loading data to the 
product . 

8. A system in accordance with claim 6 or claim 7, 
wherein the control involves the product management means 
receiving data from the product via the system. 

9. A system in accordance with claim 8, wherein the 
data is transaction data. 

10. A system in accordance with any one of claims 6 
to 9, wherein the control involves the product management 
means downloading product applications directly to a card 
or device. 

11. A system in accordance with any one of claims 6 
to 10, wherein the system is arranged so that data 
associated with the product and provided to the product 
management means or to the card or device from the product 
management means may be routed via the message management 
means of other entities participating in the system. 

12. A system in accordance with any one of the 
preceding claims, wherein the card management means is 
arranged to store product owner identification data, 
identifying product owner participants responsible for 
managing products associated with cards managed by the card 
manager participant . 

13. A system in accordance with any one of the 
preceding claims, wherein the device management means is 
arranged to store product owner identification data, 
identifying product owner participants responsible for 
managing products associated with devices managed by the 
device manager participant, and card accepter 
identification data, identifying card accepters using 
devices managed by the device manager participant. 
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14. A system in accordance with any one of the 
preceding claims, wherein the product management means is 
arrahged to store card manager identification data 
identifying card managers managing cards supporting 

5 products managed by the product owner participant. 

15. A product management system, comprising a product 
management means which enables a product owner participant 
to perform a product management role alone, without 
managing cards and without managing devices, wherein the 

10 system is arranged to facilitate the product owner 
participant to directly affect control of a product 
associated with a card or device. 

16. A system in accordance with claim 15, wherein the 
control of the product involves loading data to the 

15 product. 

17. A system in accordance with claim 15 or claim 16, 
wherein the control involves the product management means 
receiving data from the product. 

18. A system in accordance with claim 17, wherein the 
20 data is transaction data. 

19. A system in accordance with any one of claims 15, 
16 or 17, wherein the control involves the product 
management means downloading product applications to a card 
or device. 

25 20. A system in accordance with any one of claims 15 

to 20, wherein the product management means is arranged to 
store card manager identification data identifying card 
managers managing cards supporting products managed by the 
product owner participant. 

30 21. A card management system, including a card 

management means which enables a card manager participant 
to perform a card management role alone, without managing 
products associated with a card and without managing 
devices. 
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22. A card management system in accordance with claim 
19, wherein the card management means is arranged to store 
product owner identification data, identifying product 
owner participants responsible for managing products 

5 associated with cards managed by the card manager 
participant . 

23. A device management system, including a device 
management means which enables a device manager participant 
to perform a device management role alone, without managing 

10 products associated with a card and without managing cards. 

24. A device management system in accordance with 
claim 21, wherein the device management means is arranged 
to store product owner identification data, identifying 
product owner participants responsible for, managing 

15 products associated with devices managed by the device 

manager participant, and card accepter identification data, 
identifying card accepters using devices managed by the 
device manager participant. 



20 including a plurality of service processing means, each 
service processing means enabling a participant to the 
system to carry out at least one of card, device and 
product management, and a message management means provided 
to each participant in the system and arranged to act as a 

25 communications interface routing message data between each 
of the service processing means and between cards and 
devices, to enable a network of service processing means 
and a plurality of participants to interface to carry out 
card, device and product management. 

30 26. A card, device and product management system 

including a network comprising a plurality of nodes, each 
node comprising a service processing means enabling a 
system participant to carry out at least one of card, 
device and product management, and a message management 

35 means arranged to act as a communications interface routing 
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message data between the service processing means of each 
node and between cards and devices. 

'27. A system in accordance with claim 26, wherein the 
service processing means includes a device management means 
5 which enables a device manager participant to perform a 
device management role alone, without managing products 
associated with a card and without managing cards. 

28. A system in accordance with claim 26 or claim 27, 
the service processing means including a card management 

10 means which enables a card manager participant to perform a 
card management role alone, without managing products 
associated with a card and without managing devices. 

29. A system in accordance with any one of claims 26, 
27 or 28, wherein the service processing means includes a 

15 product management means which enables a product owner 
participant to perform a product management role alone, 
without managing cards and without managing devices. 

30. A method of managing cards, devices and products, 
comprising the steps of defining a tripartite environment 

20 for card management, the card management tripartite 
environment comprising ; 

a card manager participant responsible for managing 
non-product specific card operations ; 



25 devices for accepting cards and for carrying out product 
transactions; and 

a product manager participants, responsible for the 
management of product-related aspects of the card 
environment, wherein the device manager participant, card 

30 management participant and product manager participant may 
be separate entities. 

31. A method in accordance with claim 30, comprising 
the further step of providing a computer system including 
modules enabling each of the card manager participant, 
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device manager participant and product manager participant 
roles to be carried out separately from each other. 

1 32 . A method in accordance with claim 30 or claim 31, 
comprising the step of enabling the system to facilitate 
the product manager participant to have direct access to a 
product in order to directly affect control of a product 
associated with a card or device. 

33. A method in accordance with claim 30, comprising 
the step of enabling the product owner participant to load 
data onto the product. 

34. A method in accordance with claim 32 or claim 33, 
comprising the step of enabling the product owner 
participant to receive data from the product. 

35. A method in accordance with- claim. 34, wherein the 
data is transaction data. 

36. A method in accordance with any one of claims 32 
to 35, comprising the step of the product owner participant 
downloading a product application to a card or device. 

37. A method of managing products, comprising the 
steps of defining a product manager participant, 
responsible for the management of products alone, without 
managing cards and without managing devices, and providing 
the facility for the product manager participant to 
directly affect control of a product associated with a card 
or device. 

38. A method in accordance with claim 37, including 
the step of providing the facility to enable the product 
owner participant to load data to the product. 

39. A method in accordance with claim 37 or claim 38, 
including the step of providing the facility to enalbe the 
product manager participant to receive data from the 
product on the card or device. 

40. A method in accordance with claim 39, wherein the 
data is transaction data. 
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41. A method in accordance with any one of claims 37 
to 40, including the step of providing the facility to 
enabl'e the product owner participant to download product 
applications to a card or device. 
5 42. A method of managing cards, comprising the steps 

of defining a card manager participant whose role is to 
perform management of cards alone, without managing 
products associated with a card and without managing 
devices . 

10 43. A method of managing devices, comprising the 

steps of defining a device manager participant whose role 
is to perform management of devices alone, without managing 
products associated with a card and without managing cards. 
44. A generic system for the management of cards, 

15 devices and products, the system including a card 

management module, a device management module and a product 
management module, which can be used separately and 
networked with each other to enable different entities to 
carry out card management, device management and product 

20 management alone, and to network with other similar systems 
to facilitate card, device and product management. 

Dated this 22nd day of September 1999 
CARDS ETC 
25 By their Patent Attorneys 
GRIFFITH HACK 



# 




Pnoovcr 



53 




Issuing 



Agent 



Smart 



£ard 











^ 






Card 








Management 






5 1 



Is 



Personalisation 
Machine , 



Cardholder 




-On-line transaction - 
Off-line transaction 
- Batch transaction 



71. 



Smart Card 



70 



mm 

Device 
Management 





_ ... i 








2a 


Device ' 


2b 



•71 



THIS PAGE BLANK (uspto) 



